Tasks:

• figure out the best place to store the resources
  • on Mac it should probably be /Library since initially it won't be an runnable application
  • on Windows it is could be at the root of the c drive but it is probably better to put it in some kind
    of library location.
  • Sam and Stephen have been asked to check with their sys admins about these locations: Standard JIL Install Location

• BitRock testing BitRock
  • try making a simple Mac installer
  • try making a simple Windows installer
  • try putting some file in java.home see if it can put the file in all java.homes
    • bitrock cannot put the file in all the java.home. It also would require some trickery to just find the java.home folder. It only has ways of finding the java executable.
  • try building the installers on one of our linux servers

• based on issues above decide if it is better to use java.home or environment variable
  • the current plan is to install the software in one location for each platform so the user of the installer won't have choice. However this is pending on the responses from the sys admins.

• ask admins we are working with what they use for installing applications on all of the computers.
  • Sam and Stephen have been asked to check with their sys admins

• create a boot strap jar which sets up this url caching mechanism and is passed the caching patterns, and jnlp file.
  • try to keep this jar under 20k with the expectation that it will downloaded each time the application starts.
  • use the jnlp2shell code for parsing the jnlp file, requesting the jars
  • the jars will be cached in a subfolder of the resource folder, (the other subfolder will be for the resources) just using the cache format used by the existing jnlp to shell code.
  • the boot strap app then loads these jars and runs the main class of the jnlp
    • it also needs to set the java.libary.path to include the native libraries specified in the jnlp file. jnlp2shell already handles this.
  • update the jnlp2shell cache format so it doesn't create really long paths which will break on windows.
  • the bootstrap app will either look for an env variable or a properties file in java.home to find its resource location, see the above task.
  • it should look for a system property which defines a url to use if the resource folder is not found. That url can contain instructions about installing the application.

• use java's url cache mechanism: http://java.sun.com/j2se/1.5.0/docs/guide/net/http-cache.html to find the application resources.
  • a url pattern matching is used so only urls matching those patterns will be looked for in the cache. This can then point to "tagged" locations of files.
  • the file contents is stored as sha1 named files based on the file content.
  • a mapping file is maintained which goes from from url to sha1 (multiple urls might point to the same sha1)
  • the cache policy is set to never update. this makes things faster as long as it only caches "tagged" file locations.

• update the scripts for caching the resources of a otml file so it caches them in the format of the URL cache above.
  • these scripts already exist and have been used to make offline versions of activities. Aaron wrote them originally.

• create a mac and windows installer which can install the jar and resource caches.
  • allow the user to specify an alternative install location. This will then be set in either the env variable or in a properties file in java.home. see above.

• add a mechanism to set "default" system properties in the property file in the resource folder. This can be used to override the default location of SailUserData folder to support the deep freeze folks.

• add mechanism to generate the wrapper jnlps for all of our current jnlps.

• add mechanism to investigation site to generate the wrapper jnlps.

• test this on windows 2000, XP, Vista and OSX 10.4 and 10.5

• try to find a way to deal with mozswing install
  • even the old mozswing can be pointed to a location with a system property or static method call. So there might be a straight forward way to do this.

• try to find a way to deal with drivers install
  • examples of this are the LabPro drivers and ftdi drivers for dataharvest
  • hopefully this can be integrated with bitrock

Env Var versus Java Home:

• is it easier to find java.home or to set an environment variable with an installer?
  • the reason for this is to store a property that indicates where the resources are stored.
  • finding java.home is tricky because there are multiple java folders. this should be a common problem for installers installing java extensions, (http://java.sun.com/j2se/1.4.2/docs/guide/extensions/spec.html) so maybe it has an easy solution
  • setting an env var is easy on mac (should just be creating or editing a file) but I think it requires a reboot to take effect, which would be annoying. setting the env var on windows probably requires calling an api or setting a registry key.
• java can read env vars without needing native code.
• setting env var with an installer is pretty easy but it probably requries a reboot or at least a log out and log back in.
• finding the correct java.home might be tricky.
• handling the case when java is updated and java.home changes is also tricky.
• the benifit of finding java home is that we could then install an extension there and then we would not need to run trusted webstart applications or applets.

Mac Installer:
– probably it is better to use a package installer
– make a test one
– figure out the options for admins to do mass installs of package installers.
– figure out if we can build package installers with a task on linux
– include Web Start Fix

Now Unnecessary Tasks

• look into Apple and Windows java updates: if something is installed into the java.home:
  • do these updates erase it?
  • do the updates create a new folder so the thing won't be found again?

• look into enumerating drives on windows.
  • inorder to support deep freeze people, the boot.jar can't use a env var, or java.home change.
  • so by getting all of the drives and looking for some special file or folder, these computers can be supported.
  • this should be done without native code since some schools prevent users from creating dlls on their computer. And this then crashes webstart when it tries to create them.

• Bitrock
  • try setting an environment variable (is a reboot needed before that variable is visible?)
  • see if bitrock can support signing files
  • see if bitrock can support online installers that are small and then download just the files that are needed.

I've added a task to incorporate the Web Start Fix. Posted by abean at Jul 30, 2009 17:21